Method and Apparatus for Software Updating

ABSTRACT

A computer-implemented method includes receiving a restore command to restore a vehicle computing system (VCS) system state. The method further includes restoring a base system state to a known, functional state and obtaining a list of applications previously installed on the VCS. The method also includes for each application previously installed on the VCS, finding a version of the application compatible with the restored base system state. Also, the method includes installing the version of each application compatible with the restored base system state.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.13/206,615 filed Aug. 10, 2011, the disclosure of which is incorporatedin its entirety by reference herein.

TECHNICAL FIELD

The illustrative embodiments generally relate to a method and apparatusfor software updating.

BACKGROUND

With advances in computing technology presenting new opportunitiesconstantly, it is often desirable to update an operating system. Formingthe backbone of a platform, the operating system brings together all thecomponents of a computing system into a functioning base from whichnumerous software applications can be launched.

PC operating systems often have many updates available. Either to betteruse existing resources or to optimally use newly available technology,operating system updates can provide an ever improving fundament onwhich an end-user experience can be built. Whether it is a new operatingsystem entirely, or a version update to an existing system, there arenumerous reasons why a user may wish to update an operating system on aPC.

In the PC-model of the computing platform, once a PC is purchased it isgenerally up to a user to update the operating system. Since themanufacturer typically has little to no contact with the PC once theinitial purchase is made, a user must rely on their own desire andactions to provide updates to the system. Some operating systems mayhave automatic download of new patches and updates provided therewith,but again, it is typically the user that initiates this auto-updateprocess, and it is on the shoulders of the user to ensure that existingsoftware products will work with the new operating system.

Another model now exists, however, that of mobile computing. Devicessuch as PDAs, smartphones, and even vehicles may carry mobile computingsystems therein, and the providers of these devices in many cases willstill have a vested interest in ensuring the continued functionality ofthe device.

For example, a smartphone not only serves as a portable computingdevice, but it also serves as a platform from which cellular phone callsmay be made. Since there is typically a service contract associated withthe device, often for both cellular and data transfer services, it is inthe best interest of the service provider to ensure that operatingsystem updates are performed on the device as needed.

At the same time, as with personal computers, software developers areconstantly developing applications for use on mobile computing devices.Since many of these devices only have limited restrictions on the natureand details of a particular application that may be developed for thedevice, it may be difficult for the manufacturer/provider of the deviceto ensure that all applications are compatible with a new operatingsystem or operating system version. Consequently, changes to theoperating system may cause certain applications to function differently,or to lose functionality altogether.

Thus, it is typically incumbent on the user to ensure that a new versionof a particular application is downloaded and installed when anoperating system is updated. Similarly, developers must make sure thatthe applications are kept up to date so as to function on new versionsof operating system software/firmware.

Unlike the world of PCs, however, because device providers in the mobilecomputing world typically maintain a more integrated relationship withthe consumers using their products, consumers may tend to misplace faultwith the system provider if an operating system update disables orrenders unusable one or more of the applications installed on the mobilecomputing device.

SUMMARY

In a first illustrative embodiment, a computer-implemented methodincludes receiving a restore command to restore a vehicle computingsystem (VCS) system state. The illustrative method further includesrestoring a base system state to a known, functional state and obtaininga list of applications previously installed on the VCS.

In this embodiment, the illustrative method also includes for eachapplication previously installed on the VCS, finding a version of theapplication compatible with the restored base system state. Also, theillustrative method includes installing the version of each applicationcompatible with the restored base system state.

In a second illustrative embodiment, a machine readable storage mediumstores instructions that, when executed, cause a processor of a vehiclecomputing system (VCS) to execute a method including receiving a restorecommand to restore a VCS system state. The method also includesrestoring a base system state to a known, functional state and obtaininga list of applications previously installed on the VCS.

In this embodiment, the method further includes for each applicationpreviously installed on the VCS, finding a version of the applicationcompatible with the restored base system state. The method also includesinstalling the version of each application compatible with the restoredbase system state.

In a third illustrative embodiment, a system includes a vehiclecomputing system (VCS) a vehicle computing system (VCS), a diagnosticservice tool (DST) and a remote global in-vehicle information system(GIVIS). In this embodiment, the DST is operable to generate a restorecommand to the GIVIS.

Also, in this embodiment, upon receiving the restore command, the GIVISis operable to download and install a known, functional VCS operatingsystem on the VCS. Following installation of the operating system, theVCS is further operable to communicate with the GIVIS to receive, foreach application previously installed on the VCS, a most recent versionof the application, compatible with the installed operating system.Additionally, the GIVIS is operable to instruct installation each of themost recent versions of the applications compatible with the installedoperating system on the VCS.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative example of a vehicle computing system;

FIG. 2 shows an illustrative example of a software maintenanceecosystem;

FIG. 3 shows an illustrative example of a software maintenance model;

FIG. 4 shows an illustrative example of a software update process;

FIG. 5 shows an illustrative example of a second software updateprocess;

FIG. 6 shows an illustrative example of a restoration process; and

FIG. 7 shows an illustrative example of an operating system updateprocess.

DETAILED DESCRIPTION

As required, detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely exemplary of the invention that may be embodied in variousand alternative forms. The figures are not necessarily to scale; somefeatures may be exaggerated or minimized to show details of particularcomponents. Therefore, specific structural and functional detailsdisclosed herein are not to be interpreted as limiting, but merely as arepresentative basis for teaching one skilled in the art to variouslyemploy the present invention.

FIG. 1 illustrates an example block topology for a vehicle basedcomputing system 1 (VCS) for a vehicle 31. An example of such avehicle-based computing system 1 is the SYNC system manufactured by THEFORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computingsystem may contain a visual front end interface 4 located in thevehicle. The user may also be able to interact with the interface if itis provided, for example, with a touch sensitive screen. In anotherillustrative embodiment, the interaction occurs through, button presses,audible speech and speech synthesis.

In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controlsat least some portion of the operation of the vehicle-based computingsystem. Provided within the vehicle, the processor allows onboardprocessing of commands and routines. Further, the processor is connectedto both non-persistent 5 and persistent storage 7. In this illustrativeembodiment, the non-persistent storage is random access memory (RAM) andthe persistent storage is a hard disk drive (HDD) or flash memory.

The processor is also provided with a number of different inputsallowing the user to interface with the processor. In this illustrativeembodiment, a microphone 29, an auxiliary input 25 (for input 33), a USBinput 23, a GPS input 24 and a BLUETOOTH input 15 are all provided. Aninput selector 51 is also provided, to allow a user to swap betweenvarious inputs. Input to both the microphone and the auxiliary connectoris converted from analog to digital by a converter 27 before beingpassed to the processor. Although not shown, numerous of the vehiclecomponents and auxiliary components in communication with the VCS mayuse a vehicle network (such as, but not limited to, a CAN bus) to passdata to and from the VCS (or components thereof).

Outputs to the system can include, but are not limited to, a visualdisplay 4 and a speaker 13 or stereo system output. The speaker isconnected to an amplifier 11 and receives its signal from the processor3 through a digital-to-analog converter 9. Output can also be made to aremote BLUETOOTH device such as PND 54 or a USB device such as vehiclenavigation device 60 along the bi-directional data streams shown at 19and 21 respectively.

In one illustrative embodiment, the system 1 uses the BLUETOOTHtransceiver 15 to communicate 17 with a user's nomadic device 53 (e.g.,cell phone, smart phone, PDA, or any other device having wireless remotenetwork connectivity). The nomadic device can then be used tocommunicate 59 with a network 61 outside the vehicle 31 through, forexample, communication 55 with a cellular tower 57. In some embodiments,tower 57 may be a WiFi access point.

Exemplary communication between the nomadic device and the BLUETOOTHtransceiver is represented by signal 14.

Pairing a nomadic device 53 and the BLUETOOTH transceiver 15 can beinstructed through a button 52 or similar input. Accordingly, the CPU isinstructed that the onboard BLUETOOTH transceiver will be paired with aBLUETOOTH transceiver in a nomadic device.

Data may be communicated between CPU 3 and network 61 utilizing, forexample, a data-plan, data over voice, or DTMF tones associated withnomadic device 53. Alternatively, it may be desirable to include anonboard modem 63 having antenna 18 in order to communicate 16 databetween CPU 3 and network 61 over the voice band. The nomadic device 53can then be used to communicate 59 with a network 61 outside the vehicle31 through, for example, communication 55 with a cellular tower 57. Insome embodiments, the modem 63 may establish communication 20 with thetower 57 for communicating with network 61. As a non-limiting example,modem 63 may be a USB cellular modem and communication 20 may becellular communication.

In one illustrative embodiment, the processor is provided with anoperating system including an API to communicate with modem applicationsoftware. The modem application software may access an embedded moduleor firmware on the BLUETOOTH transceiver to complete wirelesscommunication with a remote BLUETOOTH transceiver (such as that found ina nomadic device). Bluetooth is a subset of the IEEE 802 PAN (personalarea network) protocols. IEEE 802 LAN (local area network) protocolsinclude WiFi and have considerable cross-functionality with IEEE 802PAN. Both are suitable for wireless communication within a vehicle.Another communication means that can be used in this realm is free-spaceoptical communication (such as IrDA) and non-standardized consumer IRprotocols.

In another embodiment, nomadic device 53 includes a modem for voice bandor broadband data communication. In the data-over-voice embodiment, atechnique known as frequency division multiplexing may be implementedwhen the owner of the nomadic device can talk over the device while datais being transferred. At other times, when the owner is not using thedevice, the data transfer can use the whole bandwidth (300 Hz to 3.4 kHzin one example). While frequency division multiplexing may be common foranalog cellular communication between the vehicle and the internet, andis still used, it has been largely replaced by hybrids of with CodeDomain Multiple Access (CDMA), Time Domain Multiple Access (TDMA),Space-Domian Multiple Access (SDMA) for digital cellular communication.These are all ITU IMT-2000 (3G) compliant standards and offer data ratesup to 2 mbs for stationary or walking users and 385 kbs for users in amoving vehicle. 3G standards are now being replaced by IMT-Advanced (4G)which offers 100 mbs for users in a vehicle and 1 gbs for stationaryusers. If the user has a data-plan associated with the nomadic device,it is possible that the data-plan allows for broad-band transmission andthe system could use a much wider bandwidth (speeding up data transfer).In still another embodiment, nomadic device 53 is replaced with acellular communication device (not shown) that is installed to vehicle31. In yet another embodiment, the ND 53 may be a wireless local areanetwork (LAN) device capable of communication over, for example (andwithout limitation), an 802.11g network (i.e., WiFi) or a WiMax network.

In one embodiment, incoming data can be passed through the nomadicdevice via a data-over-voice or data-plan, through the onboard BLUETOOTHtransceiver and into the vehicle's internal processor 3. In the case ofcertain temporary data, for example, the data can be stored on the HDDor other storage media 7 until such time as the data is no longerneeded.

Additional sources that may interface with the vehicle include apersonal navigation device 54, having, for example, a USB connection 56and/or an antenna 58, a vehicle navigation device 60 having a USB 62 orother connection, an onboard GPS device 24, or remote navigation system(not shown) having connectivity to network 61. USB is one of a class ofserial networking protocols. IEEE 1394 (firewire), EIA (ElectronicsIndustry Association) serial protocols, IEEE 1284 (Centronics Port),S/PDIF (Sony/Philips Digital Interconnect Format) and USB-IF (USBImplementers Forum) form the backbone of the device-device serialstandards. Most of the protocols can be implemented for eitherelectrical or optical communication.

Further, the CPU could be in communication with a variety of otherauxiliary devices 65. These devices can be connected through a wireless67 or wired 69 connection. Auxiliary device 65 may include, but are notlimited to, personal media players, wireless health devices, portablecomputers, and the like.

Also, or alternatively, the CPU could be connected to a vehicle basedwireless router 73, using for example a WiFi 71 transceiver. This couldallow the CPU to connect to remote networks in range of the local router73.

In addition to having exemplary processes executed by a vehiclecomputing system located in a vehicle, in certain embodiments, theexemplary processes may be executed by a computing system incommunication with a vehicle computing system. Such a system mayinclude, but is not limited to, a wireless device (e.g., and withoutlimitation, a mobile phone) or a remote computing system (e.g., andwithout limitation, a server) connected through the wireless device.Collectively, such systems may be referred to as vehicle associatedcomputing systems (VACS). In certain embodiments particular componentsof the VACS may perform particular portions of a process depending onthe particular implementation of the system. By way of example and notlimitation, if a process has a step of sending or receiving informationwith a paired wireless device, then it is likely that the wirelessdevice is not performing the process, since the wireless device wouldnot “send and receive” information with itself. One of ordinary skill inthe art will understand when it is inappropriate to apply a particularVACS to a given solution. In all solutions, it is contemplated that atleast the vehicle computing system (VCS) located within the vehicleitself is capable of performing the exemplary processes.

FIG. 2 shows an illustrative example of a software maintenanceecosystem. This illustrative embodiment shows one non-limiting exampleof a relationship between a vehicles computing system, consumer devices,dealerships/service centers, OEM assembly and module suppliers.

In this example, the core of the mobile computing platform is the VCSmodule 299. This module represents the current version of the operatingsystem installed on the VCS, and any applications and applicationversions also installed in the system. Updates to this module,especially to the operating system, should attempt to preserve as muchcompatibility as possible, so that applications function in the mannerin which users expect and avoid being disabled.

One point of initial configuration for this module may be the OEMassembly plant 260. At some point during vehicle assembly, the VCSmodule 299 may have a variety of software applications installed thereonvia, for example, a wireless access point 265. The wireless access pointcan receive the particular software “parts” to be installed from the newplant floor system (PFS) 263. The PFS may receive module software partsfrom an in-vehicle software (IVS) system 240, which can also send thoseparts (or at least record of those parts) to the GIVIS system 220.

For example, without limitation, if a navigation system is detected in avehicle, the VCS module will know it needs one or more software partscorresponding to the navigation system. The module can then request theneeded parts from the plant floor system.

Once all the software parts have been installed, the VCS module cancommunicate module details back to the endline system 267, which canrelay those details to an EOLX 261. This also can serve as confirmationthat all software parts were installed successfully. The information canbe sent from the EOLX to the GIVIS system 220, so that a global recordof the module details can be had.

While initial installation is ongoing, module suppliers 280 may providemodules for use in conjunction with the VCS module, including securitykeys for use of particular modules. A Module Supplier Manufacturing(MSM) system 281 may send these modules to the VCS module in anunprovisioned state. Also, the system 281 may send an enhanced supplierfeed to a GEC Hub 270, and the data from this hub can be stored in theGIVIS system to maintain a record of modules/security keys installed foruse with the VCS module.

In addition to storing the module details relayed from the EOLX, theGIVIS can relay module attributes, such as security keys to anIn-Vehicle Security system 230. System 230 can provide theencryption/decryption functionality for information passing through theGIVIS, and provides an additional layer of security by being one levelremoved from the GIVIS.

At some future point following assembly of the vehicle andinitialization of the module, a dealership 250 may have an diagnosticstool system 251 provided thereto. This system can provide commands forapplication install (along with application data) to a USB drive 255usable by a technician at the dealership to install applications andother software on the VCS module.

Record of the installation may be sent over the ODB-II Port 253 tomaintain a log of installed applications and/or application versions.Additionally, the ODB-II Port may be used by a technician to restore theVCS module to an unprovisioned state, and further to provision themodule, for example, following a restore. Software and/or commands forrestoring the module and provisioning the module may come from thediagnostics system, which may also receive a copy of the installationlog from the ODB-II Port to relay to the GIVIS. Once all applicationshave been installed and the module(s) provisioned, a module/applicationstate can be relayed from the vehicle to the GIVIS.

Consumer devices, namely, in this example, a USB drive 203 receivingdata from a consumer PC 201, may also interact with the VCS module. Theconsumer PC may have software updates usable/installable on the module,and this data may be sent to a USB drive for installation into themodule.

The consumer PC may receive this software data from a web portal system210, which can be informed of updates from the GIVIS system, whichshould know a current state of the particular VCS module, at least fromtracking installation logs and storing module details.

Once the data has been installed in the VCS module from the USB drive,an installation log can be sent from the VCS module to the USB drive,relayed to the home PC, and sent from there to the web portal system.That system can then relay the information to the GIVIS system tomaintain a current record of installed software on the VCS module.

FIG. 3 shows an illustrative example of a software maintenance model. Inthis illustrative embodiment, the GIVIS system 301 cab access anSMR/ENGINE/APA system 305 to determine available versions ofapplications 308 that may be installed with respect to a VCS module.

The GIVIS system may also interface with an IDS/PTS/ETIS/TSI system 303to provide available applications (e.g., without limitation, versions offree and previously purchased applications) that can be installed withrespect to a VCS module. Communication with system 303 may also includea get latest communication.

In a get latest communication, the system determines an installationpackage with the latest (e.g., without limitation, most up-to-date)version of a software package for a module's latest state.

In at least one example, a “free” version of software may be installed,having a first set of features. This will be branch A of a softwarelineage. Updates may be provided to the software in this version tomaintain compliance, and as long as a user elects to maintain the firstversion of the software, no cost will be incurred.

In addition, at some point, a second “paid” version of the software mayalso be available, having an additional set of features or enhancedversions of the first set of features. This will be branch B of thesoftware lineage.

If a user elects to maintain usage of the free version, then a “getlatest” command may proceed to the end of the branch A lineage,preserving the free state of the software version, while skippingintermittent updates to install the most up-to-date version of thebranch.

On the other hand, if a user had, at some point, branched to branch B,installing the paid version of the software, the “get latest” mayretrieve the most up-to-date version of that branch.

If, instead, a “get available” command was implemented, the user may bepresented with options to maintain a free version of software or toswitch to a paid version of software if both options were available andcompatible with a current state of the VCS module.

In another example, branching may occur to maintain compatibility when aplurality of modules interact with each other. Installation of a certainsoftware application that interacts with other applications may requireinstallation of a new version of applications with which the certainsoftware application interacts. Upon receiving a get latest command, thesystem may get the latest version of any of these applications thatmaintained compatibility with the other interacting applications. Uponreceiving a get available command, the system may only get availableversions of a particular application that maintains the compatibilitywith other installed, interacting applications.

Applications, and new versions of applications may be known to an LCSsystem 307 and notification of these applications may be sent to theGIVIS system. Through communication with the LCS system 310, a GIVISsystem may determine which applications and versions of applications areappropriate to present based on which command (e.g., get latest, getavailable, restore, etc.) is being executed. The IVS system may presentthe actual applications to the GIVIS system.

A restore command 302, processed between system 303 and a GIVIS system,will restore the operating state of a VCS module to a known workingstate or specified version. Of course, this may cause incompatibilitieswith existing software that is installed on the VCS module, so typicallya get latest command will be processed in conjunction with a restorecommand. Processing the get latest command should help ensure thatcompatible versions of all existing software are then obtained andinstalled on the newly restored VCS module, and functionality withrespect to the restored state should be maintained.

FIG. 4 shows an illustrative example of a software update process. Inthis illustrative example, a request is made for a latest version of anoperating system, application, BIOS, etc. 401. Software applications,for example, often have a lineage associated therewith. The versionnumber of the software may determine where in the lineage the particularversion lies, what the initial software was, what configuration orupdate decisions have been made, and what future versions or updates areavailable and compatible with that version. In certain instances,lineages branch based on configurations and installed features, andlineages forward from that point may continue down a particular branch,corresponding to the previously installed version.

In the process shown in FIG. 4, in response to the request for thelatest version, the forward lineage of existing software is ignored 403.That is, a “next” version of the software will not be installed, norwill any updates along the lineage between a current lineage locationand the end of a branch. Instead, the process proceeds to the end of anexisting branch and finds the latest version of the software compatiblewith the module and installs that version 405.

FIG. 5 shows an illustrative example of a second software updateprocess. In this illustrative example, a request is made for availableupdates to a module 501. In response to the request, a list of all freeapplications 503 and previously purchased applications 505 is compiledand provided to a user 507. The user can then peruse the list and selectwhich applications and versions of those applications should beinstalled on the module.

As previously discussed, different versions of software may providedifferent options and lineages. For example, a user may elect a certainversion of software with a get available command, and then furtherexecute a get latest command to ensure the latest, compatible form ofthe selected version is installed on a mobile computing system.

FIG. 6 shows an illustrative example of a restoration process. When arestore request is received 601, the process will first get the latestversion of an operating system and/or BIOS for installation 401, 403,405.

After the latest compatible version is installed in the VCS, the processwill then find all free and purchased applications that were previouslyinstalled on the VCS 501, 503, 505. Instead of presenting these asoptions for a user, however, a get latest command may be performed withrespect to each discovered available application that corresponds to apreviously installed application. Thus, based on the newly restoredoperating system/BIOS state, the system will install the latest,compatible versions of all previously installed applications. Theseapplications may be double-checked for compatibility and installed inthe event that they are compatible with the OS/BIOS installed inresponse to the restoration request 603.

In the event that any incompatibilities exist between the previouslyinstalled applications and the newly installed operating system, thesystem will report the incompatibilities to the user 605 so that theuser is aware that those applications may not function on the newsystem.

FIG. 7 shows an illustrative example of an operating system updateprocess. In this illustrative example, an update to the operating systemis detected 701. Because incompatibilities may exist with installedapplications, it is determined if any existing applications areinstalled on the mobile computing platform 703.

If no applications have been installed, or if all installed applicationsare compatible with the newly update operating system, the processexits. This varies from a typical computing environment, where a usermust ensure the existing compatibility of applications by manuallychecking some or all of the applications for continued compatibility.

If at least one un-verified application exists 703, that application ischecked by the process 705 to ensure compatibility 707. In at least oneexample, the provider of this process will know which versions ofapplications are compatible with which versions of operating systems,and the application version number can be used to determinecompatibility of that application.

If the application is incompatible in its present version 707, theprocess then determines if a compatible version of the application isavailable 709. This version could correspond to a next version of anapplication, or could be a version that is somewhere further down alineage from the current version of the installed application.

The compatible version may be downloaded to the platform at this point711. This version could correspond to a first compatible version of theapplication, or it could correspond to a more recently available versionof the application, beyond a point of first compatibility. In thismanner, users can not only be provided with a compatible version, butthey can be provided with the most up-to-date version of the applicationwhich is compatible. The new version of the application is theninstalled on the platform 713 and the process continues checking forincompatible applications.

If an application is incompatible 707 and no compatible version of theapplication exists 709, the user may be informed that the particularapplication has no known compatible version, and will be disabled atleast temporarily. It may then be possible for the user to check forfuture compatible versions or for the process itself to periodicallycheck for compatible versions.

Additionally or alternatively, system configurations may be storedremotely, and upon the development of a compatible version of anapplication, all systems previously having that application disabled maybe notified of the new version, or even have the new versionautomatically installed thereon.

As required, detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely exemplary of the invention that may be embodied in variousand alternative forms. The figures are not necessarily to scale; somefeatures may be exaggerated or minimized to show details of particularcomponents. Therefore, specific structural and functional detailsdisclosed herein are not to be interpreted as limiting, but merely as arepresentative basis for teaching one skilled in the art to variouslyemploy the present invention.

While exemplary embodiments are described above, it is not intended thatthese embodiments describe all possible forms of the invention. Rather,the words used in the specification are words of description rather thanlimitation, and it is understood that various changes may be madewithout departing from the spirit and scope of the invention.Additionally, the features of various implementing embodiments may becombined to form further embodiments of the invention.

What is claimed is:
 1. A system comprising: a processor configured to:receive a remote software monitoring module notification that vehiclecomputer software has an available update; responsive to thenotification, present a user with at least one of an option to selectfrom compatible newer versions of the vehicle computer software or anoption to upload a most recent compatible version of the vehiclecomputer software; and process an update selection to update the vehiclecomputer software.
 2. The system of claim 1, wherein the user is atleast provided with an option to select from compatible newer versionsof the vehicle computer software and the processor is further configuredto present selectable options corresponding to newer compatible updatesto the vehicle computer software.
 3. The system of claim 2, wherein thenewer compatible updates are updates along multiple branching lineagesof software, wherein at least one lineage corresponds to a currentlineage of the vehicle computer software and wherein at least one otherlineage corresponds to a lineage different from the current lineage. 4.The system of claim 3, wherein the processor is further configured toobtain a most recent compatible update, in a selected lineage, forinstallation.
 5. The system of claim 1, wherein the user is at leastprovided with an option to upload a most recent compatible version ofthe vehicle computer software and the processor is configured to obtaina most recent compatible update for installation.
 6. The system of claim5, wherein there are a plurality of software lineages for the vehiclecomputer software, wherein the vehicle computer software versioncorresponds to a particular lineage, distinct from at least one otherlineage, and wherein the processor is configured to obtain the mostrecent compatible update from the lineage corresponding to the vehiclecomputer software version.
 7. A computer implemented method comprising:receiving a remote software monitoring module notification that vehiclecomputer software has an available update; responsive to thenotification, presenting a user with at least one of an option to selectfrom compatible newer versions of the vehicle computer software or anoption to upload a most recent compatible version of the vehiclecomputer software; and processing, via a vehicle computer, an updateselection to update the vehicle computer software.
 8. The method ofclaim 7, wherein the user is at least provided with an option to selectfrom compatible newer versions of the vehicle computer software and themethod further includes presenting selectable options corresponding tonewer compatible updates to the vehicle computer software.
 9. The methodof claim 8, wherein the newer compatible updates are updates alongmultiple branching lineages of software, wherein at least one lineagecorresponds to a current lineage of the vehicle computer software andwherein at least one other lineage corresponds to a lineage differentfrom the current lineage.
 10. The method of claim 9, wherein the methodfurther includes obtaining a most recent compatible update, in aselected lineage, for installation.
 11. The method of claim 7, whereinthe user is at least provided with an option to upload a most recentcompatible version of the vehicle computer software and the methodfurther includes obtaining a most recent compatible update forinstallation.
 12. The method of claim 11, wherein there are a pluralityof software lineages for the vehicle computer software, wherein thevehicle computer software version corresponds to a particular lineage,distinct from at least one other lineage, and wherein the method furtherincludes obtaining the most recent compatible update from the lineagecorresponding to the vehicle computer software version.
 13. A computerreadable storage medium, storing instructions that, when executed by avehicle computer, cause the computer to perform a method comprising:receiving a remote software monitoring module notification that vehiclecomputer software has an available update; responsive to thenotification, presenting a user with at least one of an option to selectfrom compatible newer versions of the vehicle computer software or anoption to upload a most recent compatible version of the vehiclecomputer software; and processing, via a vehicle computer, an updateselection to update the vehicle computer software.
 14. The computerreadable storage medium of claim 13, wherein the user is at leastprovided with an option to select from compatible newer versions of thevehicle computer software and the method further includes presentingselectable options corresponding to newer compatible updates to thevehicle computer software.
 15. The computer readable storage medium ofclaim 14, wherein the newer compatible updates are updates alongmultiple branching lineages of software, wherein at least one lineagecorresponds to a current lineage of the vehicle computer software andwherein at least one other lineage corresponds to a lineage differentfrom the current lineage.
 16. The computer readable storage medium ofclaim 15, wherein the method further includes obtaining a most recentcompatible update, in a selected lineage, for installation.
 17. Thecomputer readable storage medium of claim 13, wherein the user is atleast provided with an option to upload a most recent compatible versionof the vehicle computer software and the method further includesobtaining a most recent compatible update for installation.
 18. Thecomputer readable storage medium of claim 17, wherein there are aplurality of software lineages for the vehicle computer software,wherein the vehicle computer software version corresponds to aparticular lineage, distinct from at least one other lineage, andwherein the method further includes obtaining the most recent compatibleupdate from the lineage corresponding to the vehicle computer softwareversion.